Object gateway for securely forwarding messages between networks

ABSTRACT

A network gateway ( 1005 ) is described, wherein an object invocation ( 1020 ) containing an embedded object reference ( 1025 ), which points to a further object ( 1002 ), is modified on passing through the gateway. The gateway validates the object invocation and enacts a number of security tests thereon before forwarding it on. In preferred embodiments, the embedded object reference is replaced by an object reference ( 1035 ) to a gateway proxy specifically for the further object ( 1002 ). The replacement object reference ( 1035 ) also includes enough information that the original object reference ( 1025 ) can be recovered. The gateway proxy is generated on or after receipt of the invocation ( 1020 ). In the event the further object ( 1002 ), which was the subject of the object reference, is itself invoked, the invocation is directed to the gateway proxy, which in turn recovers the original object reference and forwards the invocation on to the further object ( 1002 ).

TECHNICAL FIELD

The present invention relates to distributed computing systems andparticularly, but not exclusively, to gateways, and methods of operatinggateways, that are interposed between different networks in objectbased, distributed computing systems.

BACKGROUND ART

Object based systems are generally known. Presently, the best knownmodel for an object-based system, or architecture, is the Common ObjectRequest Broker Architecture (CORBA), which is supported by a consortiumcalled the Object Management Group (OMG) comprising over 700 companies.Another well known model is Microsoft's Distributed Component ObjectModel (DCOM), which shares many principles with CORBA. While many of theprinciples discussed below relate to object-based systems in general,for ease of description only, the description is directed to thespecific case of CORBA. The skilled person will appreciate, however,that the principles are more widely applicable, for example to DCOM.

CORBA can be considered as a model for middleware applications, whichdefines how blocks of intelligence, known as objects, interact across adistributed computing and communications environment. CORBA is welldocumented and will not generally be considered in any depth in thisdescription. The book “Instant CORBA” by Robert Orfali et al (publishedby Wiley Computer Publishing, John Wiley & Sons Inc., Copyright 10997,ISBN 0-1371-1081233-4), however, provides a comprehensive introductioninto CORBA and, as such, provides background to the principles describedherein.

It is usual for companies to protect their internal network, orintranet, from attacks from the public Internet by using gateways orfirewalls which monitor and restrict the flow of information between theInternet and the intranet. Some companies also have a need to deployfirewalls internally to restrict and monitor the flow of informationbetween different parts of the enterprise.

CORBA is receiving increasing attention as more and more companies adoptit as the model for the backbone for their enterprise informationarchitectures. One of the main barriers to CORBA deployment, however, isthe lack of a defined mechanism for implementing gateway or firewalltechnology.

Hereafter, the term ‘gateway’ will be used to describe any physical orlogical system or process that can be placed between networks such asthe Internet and an intranet.

It is an aim of the present invention to provide a gateway which cansupport CORBA and the like.

DISCLOSURE OF THE INVENTION

In accordance with a first aspect, the present invention provides asystem arranged to provide a gateway between a first network and asecond network the system comprising:

-   -   interface means to receive from the first network a message        intended for an object in the second network, the message        including an identifier for a further object in either the first        or second network;    -   means to generate further interface means for receiving from the        second network messages for the further object;    -   means to form a new identifier for the further interface means;    -   means to replace the received identifier with the new identifier        in the invocation; and    -   means to forward the message to the object in the second        network.

As used herein, the term ‘message’ is intended to include anytransmitted packet, or collection, of data that includes an identifier,such as a CORBA object reference. Typically, but not exclusively, amessage will comprise either an object invocation or the response froman object that was invoked by an invocation. Either or both aninvocation or a response thereto can include an identifier such as anobject reference. Also, the term ‘network’ is used in the very broadestsense, and can mean (without limitation) the Internet, an intranet orextranet, a multiplicity of networks or even a single communicationslink on one side of the gateway system.

This aspect of the invention addresses a problem that a message, such asan object invocation, can include identifiers, such as CORBA objectreferences, to other objects. Therefore, for example, an object invokedfrom across the gateway can receive such identifiers and, subsequently,use them to invoke the respective referenced objects, or pass theidentifiers somewhere else. Typically, gateways require a specificinterface, or proxy, to be in place to manage interaction with aparticular object across the gateway. One method for addressing thisissue would be to include in the gateway proxies for all possibleobjects that can be invoked. An alternative would be for all identifiersto include information about the respective proxies. However, theapplicants have addressed the issue in a slightly more complex, but farmore flexible, manner by arranging for the gateway to take steps to forma proxy for a specific object only when (or after) a correspondingidentifier is encountered.

The new identifier may include information to enable subsequent recoveryby the system of the received identifier.

In a preferred embodiment, the new identifier includes a representationof the received identifier. In an alternative embodiment, the newidentifier includes an indication of the identity of the receivedidentifier and the system includes means to associate said indicatorwith said received object reference.

Thus, for the example of the message being an object invocation, theinvoked object receives a new identifier rather than the originalidentifier. If the invoked object, acting now as an invoking object,uses the new identifier to make a further object invocation, theinvoking object will send the invocation to the specified, furtherinterface means on the gateway. Otherwise, the invoking object wouldattempt to invoke the referenced object directly, and fail due to thelack of a defined interface means in the gateway to process theinvocation. Further, since the new identifier also includes informationto enable recovery of the original identifier, and this information ispassed in the invocation, the gateway is able to receive and process theinvocation and then forward the invocation on to theoriginally-referenced object.

In a preferred embodiment, the system comprises means to include in thenew identifier an indication that the received identifier was receivedin a message from the first (or second) network. Such an indication canbe used by a gateway receiving an identifier, which is itself a newidentifier, to determine whether the gateway was the one responsible forforming the new identifier in the first place. If it was, then, ratherthan forming another new identifier, the gateway can simply revert to,or ‘unwrap’, the original identifier. Thus, only the original identifierneed be forwarded in the message to the desired destination object.

In a preferred embodiment, the system comprises means to include in thenew identifier a name tag to identify the interface means which isgenerating the new identifier.

The name tag can be used by the gateway to determine whether an objectto be invoked is available via the gateway at a later time. In a CORBAsystem, determination of the availability of the object can be madeusing a naming service call, as will be described in the detaileddescription below.

In a preferred embodiment, the system comprises means to include in thenew identifier check data for checking the validity of the or at least apart of the new identifier. The check data may comprise the result of ahash operation on the, or the at least part of the, new identifier and asecret.

The check data preferably comprises the result of a hash operation on atleast the identifier, host and port, and a secret. For example, thecheck data can be used by the gateway to verify that an invocation hasarisen from a valid new identifier previously generated by the gateway,rather than from an un-trusted source. Thus, the check data adds a highlevel of security to the gateway. In this way, even if an un-trustedparty gains knowledge of the location of a valid object on the otherside of the gateway, the party will not be able to invoke the objectwithout knowing the hash operation and, more particularly, the secret,which is stored securely by the gateway.

In a preferred embodiment, the means to generate the further interfacemeans comprises means to determine on the basis of the receivedidentifier whether a template for an appropriate further interface meansis already known to the system.

If a template is not known, the means to generate the further interfacemeans may be operable to obtain an appropriate template from a remoteinterface repository. Alternatively, or additionally, the means togenerate the further interface means may comprise means, which isoperable in the event no appropriate template is known to the systemand/or an appropriate template is not recoverable from a remoterepository, to obtain a generic template.

In any case, in a preferred embodiment, the means to generate thefurther interface is arranged to at least obtain a template for thefurther interface means on or after receipt of the received identifierand in advance of receipt of a message for the further object.

As soon as a template for the interface is available, it is a standardoperation to instantiate from the template the further interface for thefurther object. Whether the actual interface is instantiated as soon asthe template is available, or whether the interface is instantiated onlyon receipt of, for example, an object invocation, is a matter for thegateway administrator to decide. For example, if the nature of thesystem dictates that an invocation on the basis of the new identifier ishighly likely, then it would be worth instantiating the furtherinterface as soon as possible. On the other hand, if there is less of alikelihood that an invocation on the basis of the new identifier will bereceived, then it would be justifiable not to instantiate the interfaceunless an invocation were received.

By obtaining an appropriate template for an anticipated message as soonas the gateway sees an identifier in a message, the time taken toprocess an message, which is increased by the gateway needing togenerate an appropriate interface means, or proxy, to process themessage, is reduced considerably.

The obtaining of the template and instantiation of the interface meanscould occur at any time after the receipt and processing of the messagecontaining the identifier (which is used in the eventual invocation).

Clearly, in any system where the interface means is instantiated inadvance of receiving a corresponding message, state-build would occur.

A very convenient way to control such state build up, for example, is tospecify the interface means with some form of time-out, for example anhour, 24 hours, or one week, after which the interface means is deletedfrom the system. After deletion, the interface means would not beinstantly available, but would still be available, with a delay, byusing the template.

In a preferred embodiment of the present invention, the gateway isconfigured for operation within a trusted operating system environment,which preferably supports mandatory access control (MAC). Using MAC canprovide greater security for the gateway.

A particularly suitable trusted operating system is Hewlett-Packard'sVirtualVault Operating System (VVOS) based on HPUX 10.24 VVOS, whichprovides a MAC policy governing the way data may be accessed on atrusted system.

The MAC policy is a computerised version of the US Department ofDefence's long-standing multilevel security policy for handlingclassified information. The MAC policy uses labels that reflectinformation sensitivity, and maintains those labels for every processand file system object to prevent users not cleared for certain levelsof classified information from accessing it. Under MAC, users andprocesses are also assigned clearances. A clearance defines the maximumsensitivity label the user or process can access, which is necessarysince some users and processes have privileges that allow them to switchbetween sensitivity labels. Using the MAC policy, the operating systemcontrols access based on the relative sensitivity of the applicationsrunning and the files they access.

Further details of how to implement the gateway in a trusted operatingsystem are provided in the specific description below.

Preferably, the system comprises at least two logical compartments and atrusted relay process that has privileges necessary to pass messagesbetween the two compartments. Further, the first network and therespective interface means are associated with a first compartment andthe second network is associated with a second compartment.

Additionally, a secret, usable by the system in a hash operation forvalidating object references, is preferably associated with a thirdcompartment, and only the trusted relay process has the privilegesnecessary to retrieve the secret from the further compartment in orderto enact a hash operation.

It will be appreciated that the interface means can receive messagesincluding identifiers from either the first or second network, eachbeing either ‘inside’ or ‘outside’ networks, and enact the replacementof identifiers appropriately.

Preferably, in the case of CORBA, identifiers are Interoperable ObjectReferences (IOR)s including host, port and key parameters. The hostparameter defines to which host a message for the object should bedirected, the port parameter defines to which port on the host themessage should be directed and the key contains data to be passed to theobject. Also, a new identifier is preferably in the form of an IOR andhas host and port parameters which define the further interface means asthe host to which the message should be directed.

In accordance with a further aspect, the present invention provides amethod of controlling a gateway to pass messages between first andsecond networks attached to the gateway, the method comprising the stepsof:

-   -   receiving from the first network a message intended for an        object in the second network, the message including an        identifier for a further object in either the first or second        network;    -   generating means to receive messages for the further object;    -   forming a new identifier for the means to receive messages for        the further object; replacing the received identifier with the        new identifier in the message; and    -   forwarding the message to the object in the second network.

Further features of the present invention are described in the detaileddescription below and are claimed herein.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described in more detail, byway of example only, with reference to the drawings, of which:

FIG. 1 is a diagram which illustrates an example of making a CORBAobject available across a gateway to an external client;

FIG. 2 is a diagram which illustrates an example of a server returningan object reference to a client across a gateway;

FIG. 3 is a diagram which illustrates an example of a client passing anobject reference across a gateway to a server;

FIG. 4 is a diagram which illustrates an example of a scenario havingboth client and server-side gateways;

FIG. 5 is a diagram which illustrates multiple clients and servers withrespective multiple gateways;

FIG. 6 is a diagram which illustrates an example of using a namingserver with a client side gateway;

FIG. 7 is a diagram which illustrates a client according to the examplein FIG. 6 inter-operating with a server;

FIG. 8 is a diagram which illustrates an example of making only selectedservices available across a gateway;

FIG. 9 is a diagram which illustrates an example of a gateway operatingin promiscuous mode;

FIG. 10 is a diagram which illustrates how an object reference ismodified as it crosses a gateway from the inside to the outside thereof;

FIG. 11 is a diagram which illustrates how an object reference ismodified as it crosses a gateway from the outside to the inside thereof;

FIG. 12 is a diagram which illustrates how a gateway can dynamicallygenerate a proxy for an object;

FIG. 13 is a diagram which illustrates how name tags can be used tocontrol object availability;

FIG. 14 is a diagram which illustrates how location tags, oridentifiers, can be used to determine how an object reference should bemapped;

FIG. 15 is diagram which also illustrates how location tags, oridentifiers, can be used to determine how an object reference should bemapped;

FIG. 16 is a diagram which illustrates a basic scenario in which aclient and a server are separated by client and sever gateways;

FIG. 17 is a diagram which illustrates an implementation of the gatewayon a secure operating system;

FIG. 18 is a diagram which illustrates how the system of FIG. 17 managesan inbound object invocation;

FIG. 19 is a diagram which illustrates how the system of FIG. 17 isinitialised;

FIG. 20 is a diagram which illustrates how the system of FIG. 17 managesinbound object invocations requiring dynamic proxy generation;

FIG. 21 is a diagram which illustrates how the system of FIG. 17 managesoutbound object invocations;

FIG. 22 is a diagram which illustrates a full system implementation ofboth client and server side gateways implemented on secure operatingsystems; and

FIG. 23 is a diagram which illustrates an example of dynamic stub andskeleton generation and loading.

BEST MODE FOR CARRYING OUT THE INVENTION, & INDUSTRIAL APPLICABILITY

The following description uses the CORBA model in all the examples basedon HP's ‘ORB Plus’ ORB. Further, ‘messages’ are in the form of objectinvocation, or responses thereto, and ‘identifiers’ are in the form ofIORs. Although the implementation of the gateway is described in termsof HP's ORB Plus, it will be appreciated that the skilled person wouldbe capable of adapting the design to any other ORB that provides similarfunctionality. As well as running on conventional operating systems suchas HPUX or Windows NT, if they are believed to be secure enough, thegateway is preferably run on a trusted operating system such as HP'sVirtualVault, running under HP's VVOS, which provides an extremely highsecurity gateway system.

Initially, the following description describes how a gateway controlsaccess from one side thereof to objects on the other side thereof. Inparticular, the example describes in detail how the CORBA Naming Servercan be adapted very conveniently for use in controlling how objects arepublished or not across the gateway. However, the same principles can beused in other object infrastructures. In the example, the Naming Serverreturns an object reference, where one is present, in response toreceipt of a object name. This service can be likened to a telephone‘white pages’ directory.

The gateway uses only standard features of CORBA and is completelytransparent to both client and server ORBs. This means that any CORBAcompliant ORB can be used to implement client and server objects whichcommunicate via the gateway. This transparency also means that thegateway is not needed during application development and would only beneeded when the application is deployed across firewalls.

FIG. 1 illustrates, very simply, the situation to be addressed, thatbeing to provide an object gateway 100, which controls the visibility ofinternal CORBA (IIOP) services to a client 120 on the outside of afirewall or packet filter 130. In practice, the gateway 100 is locatedon a host computer system, for example a UNIX or Windows NT-basedsystem, and listens on a pre-determined communications port, so that thegateway is able to block attempts to connect to other ports on thathost. An administrator 140 wishing to make a service 110 available tothe external client 120 creates a proxy 150 for the service, via anadministrator interface 145.

The proxy 150 receives incoming invocations and forwards them to theservice 110, an object, which is on the other side of, and protected by,the gateway. The proxy 150 shares the same port as any other proxies inthe gateway 100. Before an invocation is forwarded to the service 110,the proxy 150 may perform certain checks such as checking that theinvocation is type-safe, checking that the parameters are in range andchecking that the client is authorised to make the invocation. A proxy150 may be arranged to check the results of the invocation of theservice 110, before forwarding them back to the client 120.

The client 120 is given an object reference to the proxy 150 rather thanan object reference to the service 110. Any attempt by the client 120 touse an object reference to the service 110 will fail, blocked by thefirewall, because the service 110 is on a host and port number notallowed to receive incoming packets.

One very powerful feature of CORBA is the ability to hand objectreferences between clients and servers as parameters and results. Aserver can create an object and include a reference to it in the resultthat it returns to a client. A very well know example is the CORBAnaming service “list” operation which returns an object reference to aniterator object in its reply to the client [OMG 97 a]. In accordancewith the present embodiment, the object reference needs to refer to aproxy running in the gateway, rather than iterator object itself, whichwould not be available directly through the firewall. This situation isillustrated in the embodiment in FIG. 2, in which the numbering schemecorresponds to that used in FIG. 1.

In FIG. 2, the steps are illustrated by numbered arrows which representoperations, which have corresponding steps in the following description.Thus, in the diagram:

-   -   1 when an object gateway 200 receives an invocation for the        service 210 (for example ‘list’), a proxy 250 for the service        intercepts the invocation    -   2 then, the proxy passes it on to the service 210    -   3 the service 210 processes the invocation and instantiates a        further service 215 (e.g. an iterator object)    -   4 the service 210 returns a response including an object        reference to the further service 215    -   5 the proxy 250: intercepts the response; detects the object        reference to the further service 215; dynamically creates an        appropriate new proxy 255 for the further service; and    -   modifies the object reference so that it references the new        proxy 255 instead of the further service 215    -   6 the proxy then forwards the response on to the client 220.

In this way, the gateway 200 makes the further service 215 available tothe client 220, via the new proxy 255. Conceptually, one can think ofthe gateway 200 as detecting the object reference, and replacing it witha reference to a dynamically created proxy.

Whilst this is an effective solution to making the further service 215accessible, the applicants have appreciated that it may lead to aserious ‘garbage collection’ problem: the client 220 may never use theobject reference, or the further service 215, to which the objectreference refers, may be destroyed (e.g. when the client invokes theiterator's destroy( ) operation). In general, the gateway 200, has noway to tell when the new proxy 255 is no longer needed.

FIG. 3 illustrates the equivalent problem which arises when a server 310receives from a client 320 a reference to a callback object 325. (Thisparadigm is used in the CORBA Event Service [OMG 97 a].) In more detail:

-   -   1 the client 320 generates a callback object    -   2 then client 320 then transmits an invocation to a server proxy        350    -   3 the server proxy 350 detects the callback reference and        generates an appropriate callback object proxy 356    -   4 the server proxy 350 forwards the invocation to the server 310    -   5 the server 310 processes the invocation and calls-back the        callback object as required    -   6 the callback proxy 356 intercepts the callback and forwards        the callback to the callback object 325.

Again, there is potential garbage collection problem.

So far the description has assumed that a client is not also behind afirewall. Unfortunately, in most enterprises, it will be. Thus anyobject gateway needs to provide both a client-side and server-sidesolution. FIG. 4 illustrates the basic requirements to allow a client420 and server 410 interaction, in which object references are exchangedfreely. The steps which occur are as follows.

-   -   1 The client 420 creates a client callback object 425.    -   2 The client 420 makes an invocation request containing the        reference to the client callback object 425. This call is        intercepted transparently by a client proxy 460 in the client        gateway 402.    -   3 The client proxy 460 detects the object reference for the        client callback object 425 and creates a new client callback        proxy 466 for it.    -   4 The client proxy 460 makes an invocation request replacing the        object reference with one for the new client callback proxy 466        created in step 3. The call is intercepted transparently by a        server proxy 450 in the server gateway 400.    -   5 The server proxy 450 detects the object reference in the        request and creates a new server proxy 456 for it.    -   6 The server proxy 450 sends to a server 410 an invocation        request replacing the object reference with one for the new        server proxy 456 created in step 5.    -   7 The server 410 creates a server callback object 415.    -   8 The server 410 sends a reply containing a reference to the        callback object 415 created in step 7.    -   9 The server proxy 450 detects the object reference to the        callback object 415 and creates a server callback proxy 455 for        it.    -   10 The server proxy 450 sends a reply containing an object        reference to the server callback proxy created in step 9.    -   11 The client proxy 460 detects the object reference and creates        a new server proxy 465 for it.    -   12 The client proxy 460 sends a reply containing a reference to        the new server proxy 465 created in step 11.

Even simple implementations of the above functionality would lead to thebuild up of a tremendous amount of state in busy object gateways andsubsequent garbage collection problems.

Additionally, there has only been described a single client attemptingto invoke a single server. The reality is that there will be manydifferent clients trying to use many different servers, as illustratedin FIG. 5. FIG. 5 illustrates three client gateways interacting withthree server gateways.

One way around the problems would be for server gateway administratorsexplicitly to enable access to each service being made available fromtheir internal network. The applicant's, however, do not believe this isa reasonable requirement to impose on the administrators of all clientgateways, since some enterprises may want to allow their users to invokeany service they choose. If this is the policy, it is not reasonable toexpect client administrators to anticipate and explicitly enable accessto each service their clients might want to use; they will need some wayto make their gateways ‘promiscuous’. Other client administrators maywant to allow access to any service made available by certain businesspartners, but to exercise tight control over anything else.

FIG. 6 illustrates a preferred technique, in which a gateway 600 acts asa server-side gateway providing controlled access to internal services(not shown). An administrator 640 configures the gateway 600, via anadministrator interface 645, to include a proxy 650 for a particular‘external’ naming context 670 in a Naming Server 680 [OMG 97 a] (or atrader lookup interface [OMG 97 a]). The Naming Server also includes an‘internal’ naming context 671. The external naming context 670 includesobject references, 610 and 611, for all internal services that areaccessible from outside of the gateway 600. The internal naming context671 includes object references (none shown) for all objects that areaccessible on outside of the gateway. In accordance with the presentembodiment, the external naming context 670 is known as the a “bootstrappoint”. Hereafter, it will be assumed that a Naming Server Context isused, but the same principles apply to the use of trading technol gy.

Once the gateway 600 is configured to include a proxy 650 for a namingcontext 670, that context and everything it contains becomes visible toexternal clients (not shown). Clients can browse the naming context andretrieve object references from it. The gateway 600 thus acts as atransparent proxy for any object (not shown), which is retrieved fromthe Naming Context Furthermore, the gateway 600 acts as a transparentproxy for any object which is retrieved by invoking the object, or anyobject handed by a client as a parameter to the object. This means thatthe administrator 645 must be confident that the services which areavailable in the external naming context do not introduce trap doors byhanding out object references to services which should not be madeavailable to external clients. Additionally, extra filtering technologycan be used to ensure the gateway 600 can only act as a proxy forservices on certain hosts.

If a service is removed, the respective object reference is deleted fromthe external naming context and the gateway ceases to act as a proxy forthat service and any object references obtained from that service.

Conceptually, each time the gateway sees a request or a reply with anobject reference, it creates a proxy for the object and replaces theobject reference with one for the proxy. The administrator 645bootstraps the process by choosing the bootstrap point and creates thebootstrap proxy.

Choosing the bootstrap point controls what is available through thegateway. The gateway's default behaviour is to proxy all objectsobtained directly or indirectly from a bootstrap proxy object. An objectis obtained indirectly from a bootstrap proxy object if its referencewas obtained from a third party whose object reference was itselfobtained directly or indirectly from the bootstrap proxy object. Thegateway also acts as a proxy for all objects passed as parameters inrequests to objects for which it is acting as proxy (i.e. callbackobjects).

In the preferred gateway implementation, proxies are not created eachtime an object reference passes through the gateway. The algorithmsminimise the state which the gateway needs to hold, so that many objectreferences can pass through the gateway without internal state changesoccurring. This improves the efficiency of the solution.

By default, the gateway proxies are implemented using the DynamicInvocation Interface and Dynamic Skeleton Interfaces defined in [OMG95]. This ensures that all messages relayed by the gateway are correctIIOP messages and that both requests and replies are type-safe.Alternatively, the information used to create the proxies may be used todynamically generate a template for a type-specific proxy, as will bedescribed in more detail below. Neither of these techniques, however,guarantee the application semantics will not be violated (e.g.operations called in the wrong order). Application specific proxies canbe provided to support this, as will be described in more detail below.

FIG. 7 illustrates one way in which a client gateway 702 inter-operateswith a server gateway 730 according to the preferred embodiment. In thiscase, it is assumed that a client administrator 741 wants to makeavailable to his users all services available from the server gateway730. This is achieved by creating a bootstrap proxy 760 for the Servergateway's external naming context 770 and placing the object reference790 for that proxy in a client side naming service 785 or trader, underan internal naming context 792, so that it is accessible to clients.This causes the client gateway 702 transparently to act as a proxy forthe server gateway external context 770, in the server's naming service780, or an object (not shown) retrieved from this context. Furthermore,the client gateway 702 acts as a transparent proxy for any object whichis retrieved by invoking the object, or any other object handed by theclient as a parameter to the object. This means that the administratormust be confident that the clients do not introduce trap doors byhanding out object references to services which should not be madeavailable externally. Extra filtering technology can be used to allowonly proxies for services and callback objects on certain hosts, butthis may not be an issue if the administrator has configured the objectgateway so that it interacts only with the gateways of “trusted”business partners.

Although not shown in FIG. 7, the client gateway 702 could also act inthe role of a server gateway, making services available to externalclients, by using an external context 793 of the naming server 785.Similarly the server gateway 700 could also act as a client gateway forits internal clients.

Some client administrators may not want to make all the servicesavailable from a particular site. This situation is shown in FIG. 8.Here, the client administrator 841 wishes to allow access to objects S1and S2 (not shown) only. So, the object references, 871 and 872respectively (S1 and S2), for these objects are chosen as the bootstrappoints, rather than the external Naming Context 870. First, theadministrator 841 creates a context 891 in the local naming server 885under the internal naming context 892. Next he browses the server namingservice 880 to retrieve the object references, 851 and 852 respectively,for the relevant proxy objects S1′ and S2′ and creates client sidebootstrap proxies, 893 and 894 respectively (S1″ and S2″), for these.Finally, the object references (895 and 896) for S1″ and S2″ areinserted into the local naming service 885 under the appropriate context891. The administrator's users can now retrieve object references fromtheir local naming service 885, which allows them to access S1 and S2,but no other services.

Some administrators may want to allow their clients to access anyservice they choose (promiscuous mode). As shown in FIG. 9, a convenientway of doing this is to create a bootstrap proxy 960, and correspondingbootstrap point 991 having an object reference, for some publicdirectory 990 (e.g. trader or naming service) in which serveradministrator 940 or some other party had already registered theirgateway's 900 external naming service 970 or trading service. Then, thegateway 902 acts as a proxy for any service retrieved from the publicdirectory 990 and in turn any service whose object reference wasobtained as a result of accessing the service. Thus, choosing a public“directory” service as the bootstrap point makes the gatewaypromiscuous.

In FIG. 9, the gateway 902 is entirely transparent to clients andservers. It is also transparent to other instances of the gateway. Thismeans that gateways can be daisy chained, if a request needs to traversemultiple firewalls. This will be necessary if an enterprise usesfirewalls to partition its network internally and different firewalls torestrict access to the Internet.

Security requires the integration of secure communications(authentication, confidentiality, etc) and secure platforms, for exampleone running under a trusted operating system. Secure communicationsmakes it difficult for an attacker to cause harm by intercepting amessage as it passes through the network. A secure platform makes itdifficult for an attacker to cause harm by gaining unauthorised accessto data stored on that platform (on a disc, in a process etc).

The facilities provided by VVOS to prevent information leakage are idealfor building a gateway to provide controlled access to information andservices in Internet and Intranet based environments. Note that theinstallation still makes use of firewall technology such as packetfilters. An implementation using a trusted operating system iscomplementary to conventional firewall technology, not an alternative.Its value is that the gateway machine that is visible through thefirewall is much more robust to attack than a conventional Unix orWindows NT machine.

A preferred embodiment of the present invention implemented on a secureoperating system will be described in detail below.

In order for an administrator to configure the present gateway, thegateway has an Interface Definition Language (IDL) [OMG 95] definedmanagement interface (not available to external clients). This allows anadministrator to change the configuration of the gateway. Exampleadministrative operations include: changing what operations areavailable on an object to external clients and withdrawing the rights toaccess external services from internal users. The management interfacealso allows the administrator to see what services have been madeavailable to external users and internal clients.

The present gateway also provides an API so that application specificproxies can be incorporated into the gateway. Application specificproxies can use IDL generated stubs and skeletons and allow programmersto embed knowledge of the applications' correct semantics (a simpleexample is restricting the range of parameters).

FIG. 10 is a diagram that illustrates the mechanism for mapping anobject reference 1025 in an invocation which originates from a host onthe inside of a gateway 1005 located on a host hx to the outside of thegateway. The object reference 1025 refers to an object 1002, alsolocated on the inside of the gateway. The gateway includes a proxy 1010,or interceptor, for a message 1020, which contains the object reference1025. In practice, the message 1020 will commonly be an objectinvocation for a remote object (not shown), which includes an objectkey, an operation name, and respective arguments (the details of whichare beyond the scope of the present description). The object reference1025 is included in the arguments of the invocation.

The proxy 1010 recognises the presence and location of object reference1025 in the message 1020 in one or more of a number of different ways,depending on how the overall system is configured. One way is that theremay be a pre-defined location for an object reference in a message, andthe proxy 1010 is programmed to look in that location for an objectreference. An alternative way is to provide an external database whichholds information about the positions of object references in differenttypes of message. In this case, each proxy receiving a message wouldneed to refer to the database in order to determine where to look in themessage in order to determine whether an object reference were present Afurther way of detecting the presence of an object reference would befor a message to be self-describing, to the extent that it includesinformation, for example an index portion, which could be interpreted bya proxy to determine the presence of an object reference. Clearly, oneor more of these or other similar techniques could be implemented by theskilled person in order to determine the presence of an object referencein any message.

As illustrated, the object reference 1025 comprises (in the object key)an IOR[hi: pi: ki], where h, p and k represent host, port and object keyvalues respectively for the referenced object 1002.

The proxy 1010, receives the message 1020, extracts the object reference1025 therefrom and maps the object reference to form a modified objectreference 1035. The modified object reference 1035 is contained in aforwarded message 1030.

As shown, the modified object reference includes a new host name, hx, arespective port number, px, and an object key, Kio. A detaileddescription of a mapping function, mapio, used to generate the modifiedobject reference, is provided below. The object key, Kio, includes anumber of features, as follows:

-   -   a name (or revocation) tag 1040, which is unique to the proxy        1010;    -   an identifier (or location tag) 1045, which indicates from which        side the object reference originated, which in this case is from        the inside (i);    -   an IOR 1050, which is the same as the original object reference        1025; and    -   check data 1055, which is a hash, or signature, of the name tag        1040, the identifier 1045, the IOR 1050 and a secret S.

When the message reaches a remote object, the nature of the informationin the message indicates to the remote object that an object reference(the modified object reference 1035) can be used to initiate aninvocation of the object 1002, by opening a connection with host, hx, onport, px, and sending an invocation including object key.

FIG. 11 is a diagram that illustrates the mechanism for mapping anobject reference 1125 which originates from a host 1111 on the outsideof a gateway 1105 located on a host hy to the inside of the gateway1105.

The mechanism is similar to the one in FIG. 10, and common features arelabelled accordingly, except the labels in FIG. 11 are of the form 11xx,rather than 10xx.

The significant difference is that the mapping function for thismechanism, mapoi, generates a modified object reference with an objectkey, Koi, which includes an identifier 1145, which specifies outside, o,rather than inside. Again, the mapping function, mapoi, is described indetail in detail below. A detailed description of object invocations,which pass object references in both directions, is also provided below.

FIG. 12 is a diagram that illustrates the mechanism used by a gateway1205 for dynamically receiving an object invocation 1235 containing anobject key 1240, dynamically activating a proxy 1215 and forwarding amodified message 1225.

The object key 1240 is one that was formed during a mapping as describedabove with reference to FIG. 11, and includes a name tag 1245, anidentifier 1250, which in this case is an “o” to indicate that theobject reference originated on the outside of the gateway, an IOR 1255to the destination host 1200, and check data 1260. The invocation isreceived on a port, py, of the host, hy.

The gateway 1205 is configured firstly to attempt to locate a proxy forthe object referenced in the object key 1240 of an object invocation1235 received on the port py. If no proxy is located, the gateway isconfigured then to pass the object key 1240 received on port py to anactivator function 1220, to dynamically activate the appropriate proxy1215.

The activator 1220 first checks the validity of the key by re-computingthe hash value and checking that it matches the hash value 1260 in thekey 1240. If this succeeds, the activator checks that the tag 1245 isvalid. For tags created by a naming proxy, as explained with respect toFIG. 13, this is achieved by interpreting the tag as a name andattempting to resolve the name. If any of the checks fail, the proxy isnot activated and the message is not forwarded. In the case of a CORBAinvocation, an exception is returned to the invoker.

The activator 1230 determines the type of proxy required by inspectingthe IOR 1255 of the destination object, by invoking the destinationobject 1200 to request a description of its type, or some combination ofthese two methods. If the gateway has a template for the required type,the activator 1230 uses this to instantiate the proxy 1215. If there isno specific template, the activator may either use a template for ageneric proxy, or it may generate the specific proxy dynamically.Dynamic proxy, or interceptor, generation is described in more detailbelow. As has already been described, it is advantageous to enact atleast some of the proxy activation steps in advance of receiving theinvocation, to reduce the delay caused by the activation process.

When the activator 1220 instantiates the proxy 1215, it refers to thetag 1245 in the incoming key 1240 and embeds the tag value Tagy in thenew proxy instance 1215. Tag values may be used to selectively deleteproxies.

Once the proxy 1215 has been generated, it processes the invocation, aswill be described in more detail in relation to FIGS. 14 and 15, andforwards an invocation 1225 to the destination object 1200.

FIG. 13 is a diagram that illustrates a mechanism for locating, orresolving, object references 1320 across a gateway 1300.

The diagram shows an incoming message 1301, which is a request toresolve an object name, using a naming service 1310 in CORBA. In effect,the naming service 1310 returns an object reference in response to anobject name. A similar mechanism can be used by other naming services,traders or object locators in a CORBA system or in other systems.

The message 1301 is received by a naming service proxy 1305, which isconfigured to forward all resolve requests in messages 1302 to anexternal context 1315 defined in the naming service 1310. The externalcontext 1315 is an access point in the naming service for all requestsfrom the outside of the gateway 1300.

Any objects that are available from outside the gateway 1300 have anentry 1320 in the external naming context 1315 and can thus be resolved.The result of a successful resolve request is the return by the namingservice 1310 to the proxy 1305 of a message 1330, including an objectreference 1335 for the named object. The proxy 1305 forwards arespective message 1340 to the requestor. The naming service 1310generates an exception for unsuccessful resolve requests, resulting fromthere being no respective object entry below the external context 1315.Again, the proxy 1305 forwards the exception to the requester.

In forwarding the message 1330 for a successfully resolved request, theproxy 1305 extracts the object reference 1335 and generates a modifiedobject reference 1345. The modified object reference 1345 includesspecific host and port details for the gateway and an object keycomprising a name tag 1306, an identifier, an IOR and check data, asexplained above with reference to FIG. 10.

The naming proxy 1305 contains its own name tag 1306 “Tag/” and extendsthis with the name being resolved “foo”, to create a new tag 1346“Tag/foo”, in order to permit control at the level of individual exposedservices. The tag effectively names an individual available object entryin the naming service 1310.

An administration service object 1350 may remove an available objectentry 1320 from the external context 1315 of the naming service 1310.This disables the activation of proxies by the use of any referencecontaining the tag that names the removed entry, as explained above withreference to FIG. 12. The administration service object 1350 alsoinstructs 1352 the gateway to remove all (or any) active proxies withthe tag so that any further invocation attempts are directed to anactivator (not shown) which performs the tag validation and rejects theinvocation.

FIGS. 14 and 15 are diagrams which illustrate two examples of the use ofidentifiers, or location tags.

FIG. 14 illustrates the case where an object reference 1415 is passed ina message 1410 from the outside of a gateway 1400 to the inside. Thegateway 1400, using the mapoi function, modifies the object reference1415 to form a modified object reference 1425, which is forwarded on ina message 1420.

The modified object reference 1425 includes, among other things, anidentifier 1426 and heck data 1427.

If a message 1430, including the modified object reference 1435, isreceived by the gateway 1400, from the inside thereof, the gateway usesthe mapio function on the check data 1427 to verify the contents of theobject key, Koi, by repeating the hash operation.

In the example shown, the gateway 1400 verifies the contents of themodified object key. Further, from the identifier 1426, the gateway 1400recognises that the object reference originated from the outside of thegateway 1400. Thus, the gateway 1400 ‘un-modifies’ the modified objectreference 1435, rather than modifying it again, by simply extracting theoriginal object reference 1415, and forwarding it as an object reference1445 in a message 1440.

FIG. 15 illustrates the case where an object reference has previouslybeen modified by crossing from the outside to the inside of a gateway1500, to form a modified object reference 1515. Somehow, for example byan out of band method such as email, the modified object reference 1515ended up back outside the gateway 1500. When the modified objectreference 1515 is passed in a message 1510 from the outside of thegateway 1500 again, the gateway establishes, from the identifier 1527,that the object reference originated from the outside. As a result, thegateway 1500 determines that the object reference 1515 does not need tobe modified again, and the reference simply passes through without beingmapped.

Some of the advantages of the present invention will now be considered.

In accordance with embodiments of the present invention, gateways can bedaisy-chained. In other words, object reference can cross multiplegateways, even when a gateway has no knowledge of the object that isreferenced, and an invocation of the referenced object can pass backthrough the gateways. This is a result of the present invention beingtransparent to users and system administrators alike.

The detection and replacement of object references embedded in messagesmeans that access control does not depend on end-to-end encryption orauthentication.

The gateways (or their proxies) appear to be the real “clients” and“servers” to those accessing them.

Other features and advantages of the present invention will becomeapparent to those skilled in the art of distributed systems on readingthe present description.

It will be appreciated that the examples described above generate amodified object reference which includes the original object reference.This has the benefit of making the protocol self-contained, to theextent that an original object reference can always be extracted from amodified object reference purely on the basis of the modified objectreference. However, there are other ways in which the same effect can beachieved. For example, the object gateway itself might incorporate apointer into a modified object reference, which points to a table ordatabase maintained by the gateway in which all received, originalobject references are added. In this way, an original object referencemay be recovered by using the pointer in the modified object referenceto find the original object reference in the database. An advantage ofthis is that the modified object reference can be shorter, since is doesnot acquire a full, new ‘original’ object reference each time it crossesa gateway. This can be advantageous when many gateways are to betraversed. However, a disadvantage is that the object gateways need tomaintain tables or databases, which add to complexity and potentialgarbage collection problems when object references are not used.

There now follows a detailed description of an implementation of thefeatures introduced above.

In FIGS. 16 to 23, except for a trusted relay process (TR), the labelsfollow a convention and are of the form sF[L]. s is a letter (x or y)indicating the type of service the component handles. F specifies thefunction of the component: C for client, S for server, Ii forinterceptor for inbound invocations, Io for interceptor for outboundinvocations, IR for interface repository and IRI for interfacerepository interceptor. The L suffix indicates the object locator forthe component. Some components are given multiple labels, this indicatesthat the component performs several functions, and that these functionscould be separated.

TCP connections, which are represented as black arrows, indicate thedirection in which a connection request is sent. The arrow head is atsome port that is listening, the tail of the arrow is where theconnection request occurs.

The ports are coded to indicate how exposed they are to the outside of agateway (i.e. the less trusted network, typically the open Internetunless the gateway is deployed at an internal organisational boundary).Black ports are directly exposed—these occur on the ‘outside’ face of aTR, and on external components to which the gateway connects. Externalrequests can connect directly to black ports. White ports are indirectlyexposed—these are the ports to which the relay connects in response to aconnection from outside. External requests cannot connect directly towhite ports, due to a security feature such as a firewall. Anyconnection with its tail on the ‘inside’ face of the trusted relay musthave its head at a white port. Hatched ports are not exposed to theoutside and connections to them can be made only from ‘inside’components, again, as a result of a security feature such as a firewall.On a host supporting sensitivity labels, the black and hatched portswould typically have incomparable labels. The white ports wouldtypically have the same labels as the hatched ports, but would beeffectively accessible from the outside, so would need particularattention in any security analysis.

Messages, or data packets, travelling over TCP connections arerepresented as thin black arrows, indicating the direction oftransmission of a message, and have a respective number in a circle toindicate the message order, which has an accompanying descriptionherein. Double-headed, white-filled arrows represent communicationspipes between processes.

FIG. 16 illustrates a basic scenario.

In FIG. 16, a client xC inside one firewall, F1, wishes to invoke aserver xS inside a different firewall F2. This means that the invocationmust pass out through the object gateway G1 in the first firewall F1 andin through the object gateway G2 in the other firewall F2. If there isan object reference in the invocation, e.g. a reference to yS, this mustbe transformed so that it can be used in the destination environment.Similarly, a reference passed in a response, e.g. a reference to xS,must be transformed to be usable in its destination environment.

The standard CORBA location transparency mechanisms, which allow serversto be restarted on different hosts, and to listen on different ports,must also work properly across the firewalls.

The object gateway(s) described herein provides the referencetransformation and connection establishment required for transparentaccess across the firewalls, F1 and F2. It also incorporates a mechanismto control or revoke access to servers, even where the references werepassed as parameters.

The object gateway is designed to be deployed on a host with multiplenetwork interfaces running a Trusted Operating System (e.g. VVOS)supporting Multi-Level Security. The gateway is designed for aconfiguration where the sensitivity labels are set up to preventunprivileged processes from having access to more that one network. Theobject gateway may also be deployed on conventional hosts; typically,this would be on a bastion host that is part of a firewall.

The object gateway components are described in terms of animplementation on HP ORB Plus. A description at this level is necessaryin order to understand how the components and interactions that are notnormally visible to an application programmer work across the gateway.

The object gateway design exploits the interoperability facilities thatare in the CORBA specification [OMG 95]. In particular, it uses thefeatures of IORS, and the Internet Inter-ORB Protocol (IIOP). IORs andIIOP will now be described briefly.

IORs are defined in the CORBA Specification using the following IDL:

-   -   module IOP{//IDL        -   //        -   //Standard Protocol Profile tag values        -   //        -   typedef unsigned long ProfileId;        -   const ProfileId TAG_(—)INTERNET_(—)IOP=0;        -   const ProfileId TAG_(—)MULTIPLE_(—)COMPONENTS=1;        -   struct TaggedProfile {            -   ProfileId tag;            -   sequence <octet> profile_(—)data;        -   };        -   //        -   // an Interoperable Object Reference is a sequence of        -   // object-specific protocol profiles, plus a type ID.        -   //        -   struct IOR {            -   string type_(—)id;            -   sequence <TaggedProfile> profiles;        -   };    -   //Remainder of module deleted.    -   };

For the description of the generic gateway components, the importantfeature is the sequence of tagged profiles. The type_(—)id will be usedlater when describing how to specialise some of the components.

Each tagged profile consists of a profile identifier (e.g.“TAG_(—)INTERNET_(—)IOP”) and the profile data. In the simplest IOR, fora service supporting the IIOP protocol, the profile sequence only has asingle TaggedProfile data item having the tag “TAG_(—)INTERNET_(—)IOP”.This indicates that the sequence contained in the profile_(—)data fieldis a ProfileBody, as defined in the IIOP module. Below is shown the IIOPversion 1.0 definition from [OMG 95].

-   -   module IIOP {//IDL        -   struct Version {            -   char major,            -   char minor,        -   };        -   struct ProfileBody {            -   Version iiop_(—)version;            -   string host;            -   unsigned short port;            -   sequence <octet> object_(—)key;        -   };    -   };

The ProfileBody consists of the IIOP version number, host name or IPaddress, TCP/IP port and an opaque sequence of octet (bytes) known as anobject key. The host address and port specify where the server is toconnect, and the object key is opaque and is sent over the connectionsas part of an IIOP request by the client. The server process uses thisto identify the object when it receives an invocation. Since the clientis not allowed to interpret the object key, (it is just an opaque stringof bits) the present embodiment uses this to store the object referenceof the target service accessible through the gateway.

In the present description of the gateway, the host, port and object keyare the significant data in an IOR profile. Hereafter, IORs will beshown as IOR[h:p:k] for an IOR with a single profile, so that therelevant items can be picked out in the descriptions. An IOR with twoprofiles will be written IOR[h1:p1:k1,h2:p2:k2].

For simplicity, the following description will be in terms of only someof the features of IIOP, but it will be appreciated that the relevantcomponents are built using full-function ORBs supporting the wholeprotocol. IIOP is the General Inter-ORB Protocol (GIOP) transmitted overTCP/IP; the messages transmitted are GIOP messages.

A GIOP request message, or invocation, is used to invoke an operation onsome object, or service; the response is a reply message. These are theonly message types that will be discussed herein. The relevant part ofGIOP, specified in IDL and taken from [OMG 95] is shown below:

-   -   module GIOP {//IDL        -   enum MsgType {            -   Request, Reply, CancelRequest,            -   LocateRequest, LocateReply,            -   CloseConnection, MessageError        -   };        -   struct MessageHeader {            -   char magic [4];            -   Version GIOP_(—)version;            -   boolean byte_(—)order,            -   octet message_(—)type;            -   unsigned long message_(—)size;        -   };        -   struct RequestHeader {            -   IOP::ServiceContextList service_(—)context;            -   unsigned long request_(—)id;            -   boolean response_(—)expected;            -   sequence <octet> object_(—)key;            -   string operation;            -   Principal requesting_(—)principal;        -   };        -   enum ReplyStatusType {            -   NO_(—)EXCEPTION,            -   USER_(—)EXCEPTION,            -   SYSTEM_(—)EXCEPTION,            -   LOCATION_(—)FORWARD        -   };        -   struct ReplyHeader {            -   IOP::ServiceContextList service_(—)context;            -   unsigned long request_(—)id;            -   ReplyStatusType reply_(—)status;        -   };    -   //Remainder of module deleted.    -   }

GIOP 1.1 [OMG 97B] adds support for fragmentation. This does notintroduce any new issues for the gateway. Although it is necessary tounderstand which messages are sent where, the gateway does not deal withthe messages directly. The gateway interacts with the ORB at thelanguage mapping level.

A request message consists of a GIOP message header, a Request Header,and a Request Body. The Request Body contains the ‘in’ and ‘inout’arguments. The significant elements of the request are the object key,the operation name, and the arguments. In the description below, requestmessages will be shown as k:op:args to allow these elements to bediscussed.

A reply message consists of a GIOP message header, a Reply Header and aReply Body. The content of the Reply Body depends on the status in theheader. Replies with status LOCATION_(—)FORWARD have an IOR as the body,and these are considered explicitly in the description. Replies withstatus NO_(—)EXCEPTION have the return value, inout and out parametersas the body. Other replies have the exception as the body. These casesare shown as status:results in the description as the difference is notsignificant for the behaviour of the gateway.

Although the description below explicitly considers replies with statusLOCATION_(—)FORWARD, the client ORB is responsible for processing thereply and sending the request to the new destination. The importantissues for the gateway design are identifying where the ORB needs to bemodified, and arranging the use of IORs to confine such changes to theORB supporting gateway components. It is important that the ORBssupporting the ultimate clients and servers do not need to be modified.

The overall structure of the gateway as described herein is determinedby the decision to run it on a trusted operating system that supportsMandatory Access Control and Multi-Level Security, and which supportsprivileges that allow fine-grained control over sensitive systemfacilities. In particular, the gateway is designed to run on the HPVirtualVault configuration.

The overall structure of the gateway is shown in FIG. 17.

On VirtualVault, every resource (data or process) is labelled with oneof the four sensitivity labels (SYSTEM OUTSIDE INSIDE (SOI), SYSTEMOUTSIDE (SO), SYSTEM INSIDE (SI) and SYSTEM (S)) shown in the diagram inFIG. 17, and the system enforces Mandatory Access Control rules based onthese labels.

Sensitivity labels are associated with every process and file systemobject, and are used as the primary basis for all MAC policy decisions.A sensitivity label represents the sensitivity of a process or a filesystem object and also the data each contains. If an application and thefile it attempts to access have compatible sensitivity labels, theapplication can read, write, or possibly execute the file, and each newprocess typically inherits the sensitivity label of its parenL Forexample, if a program is executed within a shell (for example, sh(1),csh(1), or ksh(1)), the new process automatically inherits thesensitivity label of the shell process. New files always inherit thesensitivity label of the process that creates them. The system canprovide special trusted programs that may be employed for changing thesensitivity label of a file after it has been created.

Sensitivity labels are also prioritised for MAC in a way that determineshow processes or objects having one sensitivity label can interact withprocesses or objects having different sensitivity labels. Theprioritisation is defined internally of the operating system and is inthe form of a ‘dominates’ relationship, in which certain sensitivitylabels dominate, or are dominated by, others. Thus, according to thearrows in FIG. 17, SO and SI dominate S, and SOI dominates SO and SI.One further important aspect of the dominates relationships is that eachsensitivity label dominates itself.

Users are generally not permitted to downgrade (by reducing therespective sensitivity labels of) any files, processes or objects whichthey control, so that the new label is dominated by the previous label.Also, users are not permitted to cross grade them so that the new labelis incomparable to the previous one. The system is also configured sothat downgrading and cross grading are not enacted automatically by theacts of reading or writing.

The effect of the MAC policy is to rigidly control information flow inthe system, from process to file to process, to prevent accidental orintentional mislabelling of sensitive information. To achieve this, forevery operation, the system compares sensitivity labels to determine ifa user or process can access an object. Any time a user or process triesto read, write, or execute a file, the system examines the process andobject sensitivity labels and consults its MAC rules. For each operationa process requests the system determines if the process has mandatoryread or mandatory write access to the object. Most restrictions that theMAC policy enforces can be summarised by the two following rules:

(1) Mandatory read access: a process can read or execute a file, searcha directory, or (subject to other privilege requirements) read thecontents of other objects if the process's sensitivity label dominatesthe object's. All of these operations involve transferring data from theobject to the process, so having such access is referred to as“mandatory read” access.

(2) Mandatory write access: a process can write to a file, remove orcreate an entry in a directory, or change any object's securityattributes (including its sensitivity label), if the process'ssensitivity label is the same as the object's. All of these actionsinvolve transferring data from the process to the object, so having suchaccess is called “mandatory write” access.

The first rule prevents a user or process that is not cleared forclassified information from seeing it. The second rule prevents a userwith a high clearance from revealing information to other users withlower clearances.

In effect, MAC ensures that information can flow only in the oppositedirection to the “dominates” relationship.

Systems such as VirtualVault do not impose the concept of anall-powerful “Super User” (e.g. “root”) or Administrator. Instead, thispower is divided up into a number of privileges. Assigning privileges toa program confers on it power to do particular actions. Programs withthese privileges are known as ‘trusted processes’. Trusted processes,such as TR, have the privileges that allow them to override the MAC.Thus, the gateway must use the TR to pass information between the insideand outside networks.

Trusted processes are typically very small programs, which are carefullydesigned to carry out a single, specific process, such as passingspecific data between compartments. Trusted processes have privilegeswhich enable them to override MAC, but these privileges are only raisedwhen required, and lowered thereafter, to minimise the chances of misuseby any other user or process. Also, a trusted process checks whether auser or other process has the right to access it, before allowing suchaccess. In this way, a correctly configured secure operating system canprovide a tightly controlled barrier between the outside network(Internet) and the inside network (Intranet).

A more detailed description of a system enforcing MAC is included in theApplicant's co-pending European Patent Application 97309328.9 filed on19 Nov. 1997.

The object gateway is structured into interceptors (also referred toherein as “interface means” or “proxies”) that do most of the work;these are shown in the diagram as ‘gI’—a generic interceptor—and‘asI’—an application specific interceptor. These are relatively largeand complex processes, and so it is not appropriate to give themprivileges to override MAC. The objective is to enable invocations fromthe outside (Internet) to reach inside services via the interceptors.The TR has the privileges required to override MAC. It is the job of theTR to ensure that all incoming invocations go to an interceptor. Theinterceptor then performs the access control functions that defend theinside objects from rogue invocations.

Although the gateway can be implemented on a conventional operatingsystem (with reduced security assurance), the description that followsincludes the TR since this introduces some issues in the construction ofIORS. It should be noted that when running under a conventionaloperating system, either a simplified form of a trusted relay may beused, or the functions performed by a trusted relay for the interceptorsmay be incorporated into the interceptors themselves.

In the description that follows, a CORBA client xC outside the firewallwill invoke a server xS inside firewall, behind the object gatewaybehind in the sense that the server is on the side from which thegateway is controlled).

FIG. 18 shows the components involved in an incoming invocation from aclient xC.

The components may be running on separate hosts or on the same host. Inthe following description, a host will be identified by the componentname prefixed with ‘h’ (e.g. hxS is the host on which xS runs).

The sequence of events for an inbound invocation starts with xC holdingthe object reference ref=IOR[hTR:p2:kxI] and making the invocationref→op(args). Initially, none of the connections is in place; forsubsequent invocations, existing connections may be re-used.

-   -   1 xC connects to hTR:p2 and sends request kxI:op:args    -   2 TR connects to hxIiL:p4 and sends request kxI:op:args—TR needs        to know to connect to hxIiL.p4 for connections accepted on p2    -   3 xIiL replies with LOCATION_(—)FORWARD to IOR[hTR:p1:kxI]—xIiL        needs to know kxI→IOR[hTR:p1:kxI], this is the standard        information that the object locator knows, except that the port        is p1 rather than p3. xIi must have created this IOR and        registered it with xIiL.    -   4 TR replies with LOCATION_(—)FORWARD to IOR[hTR:p1:kxI]    -   5 xC connects to hTR:p1 and sends request kxI:op:args    -   6 TR connects to hxIi:p3 and sends request kxI:op:args—TR needs        to know to connect to hxIi:p3 for connections opened on p1, xIi        will have instructed TR to do this as described in more detail        below.    -   7 xIi connects to hxSL:p4 and sends request        kxS:op:mapoi(args)—xIi knows kx→IOR[hxSL:p4:kxS] because        kxI=Kio(IOR[hxSL:p4:kxS]) where Kio is a function that wraps an        IOR and some other information into an object key, and xIi has        functions to verify kxI and extract the IOR. mapoi is a function        that replaces IORs in their outside form with IORs that will        work on the inside. These functions are described in more detail        below    -   8 xSL replies with LOCATION_(—)FORWARD to IOR[hxS:p5:kxS]—xSL        needs to know kxS→IOR[hxS:p5:kxS], this in the standard object        locator information.    -   9 xIi connects to hxS:p5 and sends request kxS:op:mapoi(args)    -   10 xS performs service and replies status:results (if status        signifies an exception, results is the marshalled exception)    -   11 xIi replies status:mapio(results), mapio is a function that        replaces IORs in their inside form with IORs that will work on        the outside    -   12 TR replies status:mapio(results)

Alternatively, if the object reference held by xC isIOR[hTR:p1:kxI,hTR:p2:kxI], and xC tries the profiles in order, theprocess starts at step 5. If xIi is running and TR is relaying p1 to p3,the invocation proceeds as shown. If the relay can be made to re-use thesame port number for a service if it is available, connections can bemade slightly more quickly. If the port is not available, the relay canuse any port, but in this case, the chosen port number must be passedback into the relocation mechanisms.

There may be a packet filter or other firewall component restricting theports that can be used to connect to TR from the outside. In this case,TR must choose a port for p1 from the set of ports that the externalcomponent allows. Either TR or xIi may be configured to know which portsto use. If xIi rather than TR has the information, then a protocol willbe required to deal with the case where the suggested port is already inuse, and a new suggestion is required.

If TR can be guaranteed to obtain all of the ports allocated for usefrom outside, and the mapping of external ports to interceptors isstatic for the lifetime of persistent object references to thoseinterceptors, the object locator and its relocation mechanisms are notrequired.

At step 3, xIiL may start xIi if it is not already running. Themechanism for doing this is described below.

At step 7, if the IOR embedded in kxI was IOR[hxS:p5:kxS,hxSL:p4:kxS]and xIi tries the profiles in order, the process continues from step 9rather than step 7.

Some properties of the configuration are that the only directlyaccessible ports are those on which TR is listening: p1 and p2. Also,indirectly accessible from the outside are the ports to which TRconnects: p3 and p4. TR must be running on host hTR and listening onport p2, which are in the external form IORs in order to receive theobject locator requests. Further, the interceptor xIi listens forrequests on port p3. Incoming connections on port p1 are relayed to p3,therefore the external form of reference can contain a profile referringto p1 (rather than p3), as well as containing a profile referring to p2(rather than p4).

For persistent outside references to work, port p2 must be fixed (e.g.the object locator port). The locator mechanisms fix up other ports, butre-using old ports will have a slight efficiency advantage.

The invocation described above assumes that various mappings are inplace, and IORs contain particular information. Some initialisationsteps establish this position, as illustrated in FIG. 19.

-   -   i1 xIi instructs TR to establish a relay from p1 to p3    -   i2 TR responds with actual value of p1 used    -   i3 The IOR for xIi is registered with xIiL, but with p1 rather        than p3 as the port.    -   i4 The IOR for xS is registered with xSL, this is a normal        registration.

Steps 3 and 4 have responses, but these are not shown in the diagramsince there is no significant new data in them.

Steps 1, 2 and 3 must occur in order, but step i4 is independent of theothers. Step 4 could occur before the others or at any time before step8 in FIG. 18 (the locator responding with the location of xS). Inparticular, xS may be started in response to the request from xIi forthat service (step 7 in FIG. 18).

The instructions to TR from xIi, and responses to those instructions,are sent via pipes. The idea is to ensure that unauthorised programscannot instruct TR to open connections. In order to establish the pipeconnections, xIi is started by TR. It is important that TR knows thatxIi has not been modified. xIi is relatively more sensitive than othercomponents since it can instruct TR to establish incoming connectionrelays.

Note that xIiL is shown as listening on two ports. This is because one,p4, is exposed via TR for invocation attempts to be remapped, andadministrative operations should not be exposed through that port. Alladministrative requests should arrive via p6, and this is the port thatshould appear in the IOR for the object locator (which can be found in/etc/opt/orbplus).

Interceptors such as xIi construct the IORs that are passed out toexternal clients. When creating the external reference for xS, xIi mustuse p2 as the locator port, and should use p1 as the hint port.

xIiL needs to know p4, the port on which it is to listen.Conventionally, the object locator listens on a fixed port, but if xIiLis used only via TR, p4 need not be fixed, but in this case, the portused must be made known to TR and xIiL. Static configuration is thesimpler option.

xIiL does not need to know p2, provided that xIi rather than xIiLcreates the external form IORs, or can substitute port numbers in therelevant places.

xIi needs to know p2 as locator port for inclusion/substitution in IORs.

xIi needs to know p1 as substitute for its own p3 both for use in theIOR passed to xIiL for relocation, and for inclusion in another profilein external form IORs if the short-circuit mechanism is required.

TR needs to know the p1–p3 mapping—accept a preferred p1 value from xIi,but it must be able to report the actual value used back to xIi.

TR needs to know the p2–p4 mapping, this may be statically configured.

There will now be described some possible attack strategies, and thefeature of the configuration that defeats them will be identified.

If xIiL is also the object locator for inside services:

-   -   xIiL knows the kxS→IOR:[hxS:p5:kxS] mapping.    -   A connection to hTR:p2 and request message kxS:op:args will        respond with LOCATION_(—)FORWARD to IOR[hxS:p5:kxS] through the        TR connection to xIiL.    -   An attempt to connect to hxS:p5 from outside will fail.    -   A connection to hTR:p1 with request message kxS:op:args will be        forwarded to hxIi:p3 and then fail. It fails because xIi rejects        requests with unknown object keys.    -   The attacker learns that kxS is at least partially valid as an        object key. If the attacker understands ORB Plus IORS, it can        discover that the virtual server name in the object key is        valid.

If the attacker invokes an administration operation (e.g.register_(—)sp, set_(—)command) on the object locator through port p2:

-   -   xIiL must use separate ports for administration (p6) and for        redirecting invocations (p4). Invocations sent to p2 are        forwarded to p4. If xIiL keeps these functions separate, and        does not establish a relay to p6, the request will be rejected.        N.B. this requires a modified object locator.

The CORBA Dynamic Skeleton Interface (DSI) and Dynamic InvocationInterface (DII) makes it possible to implement a generic interceptorthat can handle interfaces with any arbitrary IDL. This is in contrastto type-specific interceptors that include stub and skeleton codegenerated by an IDL compiler, and specific implementations of theoperations defined in the interface.

Clients may also use DII to invoke a service. In particular, the clientof an inbound invocation may be a generic interceptor in an outboundinvocation through another firewall as described in more detail below.

In order to support DII, a get_(—)interface operation can be invoked onany interface. This operation returns a reference to an InterfaceDef—aninterface supported by a standard service called the InterfaceRepository. The client can then invoke operations on the returnedInterfaceDef to explore the type while constructing a request with thecorrect parameter types for the operation. FIG. 20 shows what happenswhen a client using DII invokes a service through a Generic Interceptorthat also uses DII.

FIG. 20 shows the components involved in an incoming invocation from aclient that uses DII. In addition to the components in FIG. 18 thereare:

-   -   xIRI: the interceptor for InterfaceDef services in xIR    -   xIR: the Interface Repository which holds the definition of the        ‘x’ interface

The sequence of events for an inbound invocation from a client xC usingDII starts with xC holding the object reference ref=IOR[hTR:p2:kxI] andenquiring about the interface so that it can construct a request. xCdoes this by making the invocation ref→get_(—)interface( ).

-   -   1 xC connects to hTR:p2 and sends request kxI:get_(—)interface:        since it is using DII and needs information about the interface        in order to construct a request.    -   2 TR connects to hxIiL:p4 and sends request        kxI:get_(—)interface:—TR needs to know to connect to hxIiL:p4        for connections accepted on p2 as before    -   3 xIiL replies with LOCATION_(—)FORWARD to IOR[hTR:p1:kxI]—xIiL        needs to know kxI→IOR[hTR:p1:kxI] as before    -   4 TR replies with LOCATION_(—)FORWARD to IOR[hTR:p1:kxI]—these        first four steps are equivalent to the first four steps of the        inbound invocation described above. The operation is different,        but this has not yet been used.    -   5 xC connects to hTR:p1 and sends request kxI:get_(—)interface:    -   6 TR connects to hxIi:p3 and sends request        kxI:get_(—)interface:—TR needs to know to connect to hxIi:p3 for        connections opened on p1 as before    -   7 xIi replies with NO_(—)EXCEPTION:mapio(xDef)—xDef is a        reference to an object in xIR that describes interface ‘x’,        mapio translates this to the externally usable form of a        reference to an interceptor in xIRI. Let xDef be        IOR[hxIR:p8:kxD], then mapio(xDef) is        IOR[hTR:p6:Kio(IOR[hxIR:p8:kxD])] where Kio is a function that        wraps the destination IOR and some other information into an        object key.    -   8 TR replies with        NO_(—)EXCEPTION:IOR[hTR:p6:Kio(IOR[hxIR:p8:kxD])]    -   9 xC connects to hIR:p6 and sends request        Kio(IOR[hxIR:p8:kxD]):ir_(—)op:ir_(—)args invoking some        interface repository operation    -   10 TR connects to hxIRI:p7 and sends request        Kio(IOR[hxIR:p8:kxD]):ir_(—)op:ir_(—)args—TR needs to know to        connect to hxIRI:p7 for connections opened on p6    -   11 xIRI connects to hxIR:p8 and sends request        kxD:ir_(—)op:mapoi(ir_(—)args)—note that the arguments to the        interface repository operation originate on the outside, and so        mapoi is used to convert any object references in the arguments        to forms that will work on the inside.    -   12 xIR replies status:results as appropriate to the operation    -   13 xIRI replies status:mapio(results)—the results will be sent        outside so inside to outside mapping function mapio is used.    -   14 TR replies status:mapio(results); steps from 9 are repeated        until xC has enough information about the interface, operation,        and parameters    -   15 xC uses connection established at step 5 to hTR:p1 and sends        request kxI:op:args—apart from the connection already existing,        this is step 5 from the previous inbound invocation.    -   16 TR uses connection established at step 6 to hxIi.p3 and sends        request kxI:op:args.    -   17 xIi connects to hxSL:p4 and sends request        kxS:get_(—)interface:—xIi is a generic interceptor that        uses DII. Like the client at step 1, it needs to obtain        information about the interface in order to construct a request.        A generic interceptor also needs this information in order to        understand the arguments in the incoming request. xIi knows        kxI→IOR[hxSL:p4:kxS] because kxI=Kio(IOR[hxSL:p4:kxS]) where Kio        is a function that wraps an IOR and some other information into        an object key, and xIi has functions to verify kxI and extract        the IOR.    -   18 xSL replies with LOCATION_(—)FORWARD to IOR[hxS:p5:kxS]—xSL        needs to know kxS→IOR[hS.p5:kxS]    -   19 xIi connects to hxS:p5 and sends request        kxS:get_(—)interface:—this is the retry of step 17 with the        target defined by the IOR received in step 18.    -   20 xS replies with NO_(—)EXCEPTION:xDef where xDef is        IOR[hxIR:p8:kxD] as in step 7    -   21 xIi connects to hxIR:p8 and sends request        k×D:ir_(—)op:ir_(—)args—unlike step 11, the arguments originate        on the inside at xIi, so no mapping function is used.    -   22 xIR replies status:results as appropriate to the        operation—steps from 21 are repeated until xIi has enough        information about the interface, operation, and parameters    -   23 xIi uses connection established at step 19 to bxS:p5 and        sends request kxS:op:mapoi(args)—these are the operation and        arguments sent from the client at step 15. Since the arguments        originate on the outside, the outside to inside mapping function        mapoi is used.    -   24 xS performs service and replies status:results    -   25 xIi replies status:mapio(results)—the results will be sent        outside so inside to outside mapping function mapio is used.    -   26 TR replies status:mapio(results)

It should be noted that xIRI does not support all of the interfacerepository interfaces. It supports only the InterfaceDef interface, andrestricts callers to the describe_(—)interface operation.

As for the previous incoming invocation example, the round trips to theobject locator can be avoided if IORs have appropriate additionalprofiles.

At step 7, xIi responds to the get_(—)interface operation. A normalserver would find its own Interface Repository, and invoke it to look upthe appropriate InterfaceDef. The server xS does this at steps 19–20. IfxIi uses its own interface repository then xIi and xS must be using thesame interface repository, or at least interface repositories thatcontain the same definitions. This standard response to get_(—)interfaceis provided by the ORB, and no application intervention is required.

Propagating invocations across multiple firewalls requires that all theinterceptors are able to respond correctly to get_(—)interface. It isnot practical to require that interface repositories be synchronisedacross multiple independent organisations. Each interceptor mustintercept the get_(—)interface operation in the same way as otheroperations and invoke get_(—)interface on its target interface.Ultimately, the server uses the standard process to obtain an interfaceto its own interface repository.

The interceptors, such as xIi, also need the information provided by theget_(—)interface operation (steps 17–22 above). If xIi captures theresults of the invocations from xC, xIi need not invoke the interfacerepository later—i.e. steps 17–22 above will not be needed. xIi willalso be able to respond immediately using the saved information to asubsequent get_(—)interface from xC or any other client.

The ORB Plus object locator can start server processes dynamically. Itdoes this by invoking a command that has been registered for a serverprocess. This can be used to avoid having rarely used servers runningall the time—server processes can time-out and shut down, then restarton demand. This can also avoid the need to include servers in systemrestart configurations. Servers registered with the object locator canbe left to start when they are first called.

The Applicants have determined that this technique can also be appliedto interceptor processes. Starting a new type of interceptor serverwhile the gateway is running presents the same issues as startinginterceptors from the object locator.

There are two possible strategies for starting interceptors dynamically:

-   -   1 Have the object locator start the interceptor and provide a        trustworthy way for a valid interceptor to pass instructions to        the trusted relay.    -   2 Have the object locator start a program that instructs the        trusted relay to launch an interceptor.

Both of these strategies require that a program is able to establishcommunication with the trusted relay.

In the first strategy, the trusted relay has no way to verify theinstructions. It must have sufficient confidence that any program ableto establish communication is also authorised to issue instructions toestablish a connection relay. The mechanism that allows the program toestablish communication should be disabled if the executable file ismodified. If it is possible to arrange that interceptors have aprivilege that allows them to connect to the trusted relay's commandinput, this would achieve the objective.

In the second strategy, the trusted relay can consult a configurationfile, or some other resource, to obtain the parameters it needs toensure that the interceptor is acceptable, and unmodified. Once thecheck has been passed; the trusted relay can start the interceptor witha pipe connection for transmitting connection relay requests.

There now follows a description of the features of the object gatewaythat support clients behind a firewall. In particular, the descriptioncovers how outgoing invocations are processed, and how services visibleoutside the firewall can be made visible inside the firewall.

In the following example, some CORBA server yS outside the firewall willbe invoked by a client yC that is inside the firewall, behind the objectgateway (behind in the sense that the client is on the side from whichthe gateway is controlled).

The diagram in FIG. 21 shows the components involved when client yCinvokes server yS, and includes the components:

-   -   yC: the client for service ‘y’    -   yIo: the interceptor for outbound invocations of service ‘y’    -   yIoL: the object locator for ‘yIo’    -   TR: the Trusted Relay    -   yS: the server for service ‘y’    -   ySL: the object locator for yS

The components may be running on separate hosts. The host are identifiedby the component name prefixed with ‘h’ (e.g. hyC is the host on whichyC runs).

The sequence of events for an outbound invocation starts with yC holdingthe object reference ref=IOR[hyIoL:p6:kyI] and making the invocationref→op(args). Initially, none of the connections is in place; forsubsequent invocations, existing connections may be re-used.

-   -   1 yC connects to hyIoL:p6 and sends request kyI:op:args    -   2 yIoL replies with LOCATION_(—)FORWARD to IOR[hyIo:p5:kyI]—yIoL        needs to know kyI→IOR[hyIo:p5:kyI], this is standard CORBA        relocation    -   3 yC connects to hyIo:p5 and sends request kyI:op:args    -   4 yIo connects to hTR:p4 and sends request        kyS:op:mapio(args)—yIo knows kyI→IOR[hySL:p2:kyS] because        kyI=Koi(IOR[hySL:p2:kyS]) where Koi is a function that wraps an        IOR and some other information into an object key, and yIo has        functions to verify kyI and extract the IOR. (Note that Koi        wraps an outside IOR into a key for use inside, whereas Kio        which was introduced earlier wraps an inside IOR into an object        key for use outside. These functions are described in more        detail under “Mapping Object References”.) yIo also needs to        know hySL:p2→hTR:p4 (perhaps creating the mapping)    -   5 TR connects to hySL:p2 and sends request kyS:op:mapio(args)—TR        needs to know to connect to hySL:p2 for connections accepted on        p4    -   6 ySL replies with LOCATION_(—)FORWARD to IOR[hyS:p1:kyS]—ySL        needs to know kyS→IOR[hyS:p1:kyS], this is standard CORBA        relocation    -   7 TR replies with LOCATION_(—)FORWARD to IOR[hyS:p1:kyS]    -   8 yIo connects to hTR:p3 and sends request        kyS:op:mapio(args)—yIo needs to know hyS:p1→hTRp3 (perhaps        creating the mapping)    -   9 TR connects to hyS:p1 and sends request kyS:op:mapio(args)    -   10 yS performs service and replies status:results    -   11 TR replies status:results    -   12 yI replies status:mapoi(results)

Alternatively, if the object reference held by yC isIOR[hyI:p5:kyI,hyIL:p6:kyI], and the profiles are processed in order,the invocation will start at step 3.

At step 4, if yI knows kyI→IOR[hyS:p1:kyS,hySL:p2:kyS], and processesthe profiles in order, it proceeds from step 8 instead of step 4.

At steps 4 and 5 and again at steps 8 and 9, the interceptor needs toconnect to the relay rather than the host and port specified in the IOR,and the relay needs to make the onward connections. The interceptor ispassing instructions to the relay, and the relay must have a way to knowthat the instructions are trustworthy.

There are two possible approaches to establishing outbound connectionsthrough the relay:

-   -   1 A SOCKS-like approach [SOCKS] where a connection is made to        some nominated port, and the destination host and port are sent        as an in-band prefix to the main communication; or    -   2 An out of band control channel is used to set up the outbound        connection relay.

In either case, the trusted relay needs to know that the instructionsare from a source authorised to specify outbound connection relays.Outbound connections may be considered less sensitive than inboundconnections, but in the present example “inside” applications cannotconnect to the outside network. A relay that accepts instructions fromany inside process removes this feature.

The trusted relay can obtain the required assurance either by inspectingthe instructions, or by knowing that they were delivered over atrustworthy connection. The trusted relay could validate theinstructions by checking a digital signature, but this would introducesignature checking and the related certification issues into TR. So, itis better to use a connection that is trustworthy in the sense that itcannot be intercepted, and is known to originate at an authorisedcomponent.

If the destination instructions are specified over a trustworthyconnection, the SOCKS-like approach requires that all outbound trafficgo via the trustworthy connection.

With the out-of-band approach, the trusted relay is instructed toestablish a relay to some specified host and port, and replies with theport number on which it is listening for the connection from theinterceptor. If the interceptor for outbound invocations is combinedwith the interceptor for inbound invocations then the same relay controlchannel can be used for establishing inbound and outbound connectionrelays. One disadvantage of using an out of band control system is thatthe connection relay exists independently of a particular connection,and a garbage collection strategy will be required to prevent a build-upof dormant relays.

For a client to invoke an external service, it must obtain a referenceto an interceptor for the external service. The IOR mapping functionsconstruct additional references once a first reference has beenobtained. Given an internal form reference to an external namingcontext, resolving names in that context provides internal formreferences to the services. The requirement is for an interface to theoutside-to-inside mapping function of the generic interceptor, and anexternal form reference to the required external context. An internalreference to the external context can then be created and bound to somesuitable name in an internal naming context for use by clients.

The reference to the external context, and references derived from theuse of this service, may need to be revoked. This may include internalservices that have been made available externally as parameters tooutbound calls. If clients are given the use of an interceptor to theroot of the external hierarchy then the revocation is all or nothing. Bycreating an internal ‘shadow’ of the external naming structure, a finergrained revocation mechanism can be used, as will be described in moredetail bel w.

In the general case, there will be both clients and servers behind eachfirewall, and there will be firewalls at both ends in each interaction.This leads to the combined configuration shown in FIG. 22. Thecomponents are designed to be deployed on a trusted operating system,with MAC being used to prevent unprivileged processes from having accessto both networks. FIG. 22 also shows the components that must run on thetrusted hosts on a shaded background. The configuration shown here usesa simple inside/outside split as is used in VirtualVault.

The TR is the only component that requires privileges. Alternatively, asdiscussed above, it may be appropriate to grant some privilege tointerceptors. None of the other components need to run on the trustedOS, nor does any need any special ORB features. The end clients andservers, the Interface Repository and the Implementation Repository(object locator) are standard components or application components builton standard ORBs.

The descriptions above have used the functions mapio, mapoi, Kio and Koito show where object reference mapping occurs.

mapio and mapoi are used on arguments and results of invocations(including exceptions). They both work by traversing the structure andreplacing object references with the appropriate mapped form. Theimportant part of each function is the mapping it applies to an objectreference.

For an internal reference IOR[hi:pi:ki],

-   -   mapio (IOR[hi:pi:ki])=IOR[hTR:pTR:Kio(IOR[hi:pi:ki])]        where a relay has been, or will be, established from hTR:pTR to        hIiL:pIiL, the host and port for the object locator for an        interceptor that handles incoming invocations of this interface.    -   Kio(IOR[hi:pi:ki])=<tag,“i”,IOR[hi:pi:ki],h(<tag,“i”,IOR[hi:pi:ki],S>)>

The result of Kio consists of a tag which allows access to be revoked, aconstant “i” that signifies that this the embedded IOR is native to theinside of the gateway that generated this reference, the IOR, and asecure hash of these elements and a secret S.

By default, interceptors are instantiated containing the tag that theyembed in the keys generated by their Kio function. Specialisedinterceptors have the option of inventing new tags to embed inreferences that they pass out. The naming interceptor for the bootstrapcontext uses this to assign different tags to the top level services.

The secret S is used to verify that the key has not been forged. Theinterceptor that generates the object key, and any interceptor thatunwraps the key must share the secret. All interceptors in the gatewayneed to know the secret, but it need not, and should not, be knownoutside of the gateway. Alternatively, there could be a different secretfor each tag, although the advantages and disadvantages of this approachare not known.

The secret must be stored securely, since knowing this secret makes itpossible to construct an IOR that will be accepted by the gateway. Whenthe gateway is deployed on a system with MAC and Multi-Level Security,the key can be stored with a sensitivity label designated for keystorage, and for which gateway processes and other applications are notcleared. The trusted relay can be cleared to access the keys, and it canalso provide a signing function for the interceptors that are connectedto it. The existing trustworthy channel between interceptor and relaycan be used to invoke the signing and signature checking function.

For a mapped external reference, mapio can remove the wrapping andreturn the embedded IOR if it is native to the target environment (itmight not be if there is more than one gateway and they lead todifferent outsides). An external reference that comes in through thisgateway will have been mapped by the mapoi function described below. Itwill have the form:

-   -   IOR[hIoL:pIoL:Koi(IOR[ho:po:ko])]        where    -   Koi(IOR[ho:po:ko])=<tag,“o”,IOR[ho:po:ko],h(<tag,“o”,IOR[ho:po:ko],S>)>

If the object key has the expected structure, and the hash is valid, thepresence of the “o” indicates that IOR[ho:po:ko] is the correspondingexternal interface and can be returned by mapio.

If the key verifies correctly but contains “i” rather then “o”, it meansthat the IOR is the external reference to an internal service and hasbeen passed in by some out-of-band mechanism, such as email. Such areference can be used unchanged, as already described in relation toFIG. 15.

For an external reference IOR[ho:po:ko],

-   -   mapoi(IOR[ho:po:ko])=IOR[hIoL:pIoL:Koi(IOR[ho:po:ko])]        where hIoL:pIoL is the host and port for the locator for the        interceptor that deals with outbound invocations.    -   Koi(IOR[ho:po:ko])=<tag,“o”,IOR[ho:po:ko],h(<tag,“o”,IOR[ho:po:ko],S>)>

The result of Koi consists of a tag which allows access to be revoked, aconstant “o” that signifies that this the embedded IOR is native to theoutside of the gateway that generated this reference, the IOR, and asecure hash of these elements and a secret S.

Tagging references that come in is necessary in order to propagate thetags to outgoing references in nested invocations. The tags also make itpossible to revoke references to external services that have beenbrought inside as well as references to internal services that have beenmade visible outside.

In this case, the secret S protects against forgery on the inside.Forging an inside form of an external reference would make it possibleto establish a connection relay to an arbitrary outside host and port Amalicious client could forge an IOR embedding a bogus external IOR witha chosen target host and port, for example, by modifying an existing IORIf the client uses the forged reference as an invocation target, aninterceptor will be created for the bogus external service. Theinterceptor would instruct the relay to establish a connection to thehost and port chosen by the forger. If the out-of-band control is beingused, the forger can probe for the corresponding port on the relay andso establish a connection to its chosen destination. (This is anargument in favour of the SOCKS-like in-band control strategy where allconnections to the relay from the inside must come from components knownto be trustworthy—i.e. interceptors.)

For a mapped internal reference, mapoi can remove the wrapping andreturn the embedded IOR. An internal reference that went out throughthis gateway will have been mapped by the mapio function describedabove. It will have the form:

-   -   IOR[hTR:pTR:Kio(IOR[hi:pi:ki])]        where    -   Kio(IOR[hi:pi:ki])=<tag,“i”,IOR[hi:pi:ki],h(<tag,“i”,IOR[hi:pi:ki],S>)>

If the object key has the expected structure, and the hash is valid, thepresence of the “i” indicates that IOR[hi:pi:ki] is the correspondinginternal interface and can be returned by mapoi.

If the key verifies correctly but contains “o” rather then “i”, it meansthat the IOR is the internal reference to an external service and hasbeen passed out by some out-of-band mechanism, such as email. Such areference can be used unchanged.

An inbound invocation will arrive at an interceptor presenting theobject key constructed by a previous call of Kio and embedded into anIOR by mapio. It will have the form

-   -   Kio(IOR[hi:pi:ki])=<tag,“i”,IOR[hi:pi:ki],h(<tag,“i”,IOR[hi:pi:ki],S>)>        if the required interceptor instance is not currently in place,        this object key will be passed to the activator which can        instantiate the interceptor.

The activator is part of an interceptor server and has access to thesecret ‘S’. It can verify the key and check that the key contains the“i” that indicates that the service is native to the inside of thisgateway. The activator can then extract the tag and the IOR. If the tagis currently valid (i.e. has not been revoked), the activator caninstantiate an interceptor for the IOR and tag.

An outbound invocation will arrive at an interceptor presenting theobject key constructed by a previous call of Koi and embedded into anIOR by mapoi. It has the form

-   -   Koi(IOR[ho:po:ko])=<tag,“o”,IOR[ho:po:ko],h(<tag,“o”,IOR[ho:po:ko],S>)>        if the required interceptor instance is not currently in place,        this object key is passed to the activator which instantiates        the interceptor.

The activator is part of an interceptor server and has access to thesecret ‘S’. It can verify the key, and check that the key contains the“o” that indicates that the service is native to the outside of thisgateway. The activator can then extract the tag and the IOR. If the tagis currently valid (i.e. has not been revoked), the activator caninstantiate an interceptor for the IOR and tag.

The mapping functions have been shown manipulating IORs with only asingle profile. Additional profiles can be added both to avoid the useof the object locator, and to make the IORs usable if they are passed bysome means other than the gateway (e.g. stringified on a web page or ine-mail).

If mapio includes the original profile in the constructed IOR, it worksif it is passed back inside by some alternative route:

-   -   mapio(IOR[hi:pi:ki])=IOR[hi:pi:ki,hTR:pTR:Kio(IOR[hi:pi:ki])]        if the original IOR had several profiles they can all be copied.        The reverse transformation that mapoi applies will need to        remove duplicated profiles in this case.

To avoid the object locator, an additional profile can be added:

-   -   mapio(IOR[hi:pi:ki])=IOR[hTR:pTRi:Kio(IOR[hi:pi:ki]),hTR:pTR:Kio(IOR[hi:pi:ki])]        where pTRI is the port on which TR is listening for connections        that go the interceptor for the service.

Tags are embedded into the mapped IORs so that the gateway can determinethe origin of the reference that is being used to make an invocation.Some references are given distinct tags as starting points; anyreferences passed in invocations are given the same tag, and so can betraced back to one of those starting points. The tags can be used torevoke access to all references passed as a result of using some initialreference, without disturbing other references.

As has already been described, the services are bound in a context forwhich an interceptor is created, and the reference to the interceptor ispublished. In general, there can be a hierarchy of contexts under thatinitial context. The references bound in that hierarchy can be taggedwith their names relative to the root of that hierarchy by a specialisednaming interceptor.

The specialised naming interceptor performs special mappings on theobject references that are passed as parameters. In particular, thereference returned by the ‘resolve’ operation is the mapped form of theinternal reference, with a new tag chosen by the naming interceptor. Theinterceptor for the root of the externally visible hierarchy uses thename passed as a parameter to ‘resolve’. It also ensures that referencesto naming contexts are mapped from external references to otherinstances of the specialised naming interceptor.

When an operation is invoked on a sub-context for the first time, a newspecialised naming interceptor is activated with the tag that was thename of that context relative to the root of the externally visiblehierarchy. When ‘resolve’ is called on this new interceptor, itconstructs a new tag by concatenating its activation tag with the namepassed as a parameter. The external root interceptor needs no specialcode, it just needs to be activated with some chosen ‘root’ tag, andthis is propagated as a prefix to all the tags of the sub-contexts.

With this tagging system, services, and all their derived references,are revoked by unbinding them from the externally visible context.

Where external services are made visible to clients, the references alsohave tags that can be used to revoke access. References to some initialset of interceptors for external services are bound in some internalcontext. Using the names in this internal context as the tags for theinterceptors leads to the simple revocation process described below. Inthis case, interceptors used for naming contexts should not have specialtagging behaviour. The names being resolved are external names, and donot correspond to internal bindings that can be controlled.

Since interceptors are activated on demand by invocations, therevocation mechanism must block new interceptor activations. Revocationmust apply to both inbound and outbound interceptors, and the process issimilar in both cases.

With the tagging scheme described above, this is simple for referencesderived from a service that was made externally visible. The activatoris presented with a tag that is the name of the originating servicerelative to the externally visible service context, perhaps with some‘root’ tag prefix. The activator removes the prefix, then attempts toresolve the name. If the resolve succeeds, the service is stillavailable and activation can proceed.

The process can be simplified still further by making the ‘root’ tagprefix the name of the externally visible service context relative tothe internal initial naming context. The activator then just resolvesthe name, and does not need special knowledge of the external servicecontext.

Immediate revocation of active interceptors can be achieved by mappingthrough all the interceptors, shutting down all those that wereactivated with the tag that has now been revoked.

References derived from an external service are tagged with the name bywhich the interceptor for the external service is bound in the internalnaming service. Validity of the tag can be checked by resolving thename. The validation process is the same as for references derived fromexported services.

With the tagging scheme described above, a name cannot be re-used for anew service if there was an old service with that name, which wasrevoked. If the name were to be re-used, references to the old service,and other references passed by using that reference, would become usableagain.

This reincarnation of revoked references can be prevented by includingin the tag both the name and an object key. The object key is taken fromeither the exported service, or the interceptor for the importedservice. Since the interceptor activator already resolves the name inthe tag, it has the object key available for the additional check if theresolve succeeds. If the name is re-used for a new service with a newobject key, the tags will not match and the revoked references remainrevoked.

If the original service is reinstated, or a new service starts with thesame object key, then the old references will once again become valid.This is consistent with the persistence of object references.

If generic interceptors use the Dynamic Skeleton Interface and DynamicInvocation Interface in the conventional way, the processingrequirements for each invocation will be large. This will make itdifficult to achieve a high performance gateway.

Application specific interceptors process an IDL type known in advance,and are able to use the more efficient compiled skeletons and stubs.

In order to avoid implementing application specific interceptors forevery type used in an application, the performance of the genericinterceptors must be brought up to the level of the application specificinterceptors.

Dynamic interfaces use a definition of the type of an incoming requestthat contains the same information as the IDL for the type. The IDL isnormally processed by an IDL compiler into source code that is thencompiled into object code. The definition available to the dynamicinterfaces can equally well be processed by an IDL compiler. This can bedone either by generating the textual form for the standard IDLcompiler, or by adapting the IDL compiler to work directly from theavailable definition. The latter process is usually more efficient.

The IDL compiler may generate conventional source code that is thencompiled and linked into the gateway. Alternatively, the IDL compilermay generate an intermediate code that can be interpreted efficiently bythe gateway to perform the required functions. Both dynamic loading oflibraries, and the use of intermediate codes (usually called byte-codes)are well known techniques.

Since it is already known that the interceptor functions perform objectreference mapping and then call the target service, the full functionsnormally provided by stubs and skeletons are not required. There is noneed to present the arguments in the form expected by the languagemapping. The generated code can operate directly upon the structurespresented to the skeletons to produce the output normally generated bystubs. Operating at this level will be ORB-specific, but the IDLcompiler for the ORB is specifically designed to operate at this level,and can be adapted to the task.

FIG. 23 illustrates the dynamic stub and skeleton generation process.This is a variant of the process illustrated in FIG. 20, in which theinteractions with the object locator, and DII client interactions withthe interface repository have been omitted for clarity. The newcomponents are:

-   -   gIi: a generic interceptor for inbound invocations    -   cidlS: the IDL compiler server

The IDL compiler is shown as a CORBA service in order to illustrate whenit is used. In practice, it may be incorporated into the genericinterceptor, or invoked as a program, depending on the availablelanguage and operating system facilities.

The sequence of events for an inbound invocation from a client xC startswith gIi holding a reference IOR[hcidlS:p9:kcidl] to the IDL compilerserver, and xC holding the object reference ref=IOR[hTR:p1:kxI], andmaking the invocation ref→op(args).

-   -   1 xC connects to hTR:p2 and sends request kxI:op:args.    -   2 TR connects to hgIi:p3 and sends request kxI:op:args.    -   3 gIi does not have an implementation registered for kxI on the        first call, and so passes the key to its activator function. The        activator in gIi connects to hxS:p5 and sends request        kxS:get_(—)interface:—gIi needs to obtain information about the        interface in order to generate the stubs and skeletons that will        be used to process the request gIi knows kxI→IOR[hxS:p5:kxS]        because kxI=Kio(IOR[hxS:p5:kxS]) where Kio is a function that        wraps an IOR and some other information into an object key, and        gIi has functions to verify kcI and extract the IOR.    -   4 xS replies with NO_(—)EXCEPTION:xDef—xDef is IOR[h:p8:kxD], a        reference to an ‘InterfaceDef’ object in xIR that describes        interface ‘x’.    -   5 gIi connects to hxIR:p8 and sends request        kxD:describe_(—)interface:    -   6 xIR replies NO_(—)EXCEPTION:xDesc where xDesc is the        ‘FullInterfaceDescription’ for ‘x’.    -   7 gIi connects to hcidlS:p9 and sends the request        kcidl:compile:xDesc, requesting compiled skeletons and stubs        corresponding to the description xDesc    -   8 cidlS replies NO_(—)EXCEPTION:xIicode, where xIicode is the        compiled code for an interceptor specialised for ‘x’.    -   9 The activator in gIi loads the code ‘xIicode’ and registers        this as the implementation for the key kxI. The invocation        received in step 2 is passed to this new interceptor for        processing. The new interceptor in gIi uses the connection        established at step 3 to hxS:p5 and sends request        kxS:op:mapoi(args)—these are the operation and arguments sent        from the client at step 1. Since the arguments originate on the        outside, the outside to inside mapping function mapoi is used.    -   10 xS performs service and replies status:results    -   11 gIi replies status:mapio(results)—the results will be sent        outside so inside to outside mapping function mapio is used.    -   12 TR replies status:mapio(results)

The dynamically generated interceptor can remain in place to handlefurther invocations, and additional instances of the interceptor can becreated to handle other objects of the same type, without needing toregenerate or reload the code.

Unless there is an exceptionally large number of types in use, thegeneric interceptor will be able to keep the code available thusavoiding the cost of going back to the IDL compiler.

The delay on the first call can also be avoided by generating the codein advance. The server object reference is available when it is beingmapped for passing as an argument or result. The code generation couldbe performed at any time after this up to the point where theinterceptor is needed as described in the example above.

It will be appreciated that this dynamic skeleton and stub generationprocess can also be applied to a DCOM gateway since DCOM also definesthe interfaces to objects in an Interface Definition Language that isprocessed by an IDL compiler.

REFERENCES

-   [OMG 97 a] CORBAservices: Common Object Services Specification, OMG,    July 1997-   [OMG 97 b] The Common Object Request Broker: Architecture and    Specification, Revision 2.1, OMG, August 1997-   [OMG 95] The Common Object Request Broker: Architecture and    Specification, Revision 2.0, OMG, July 1995-   [SOCKS] “SOCKS Protocol Version 5”, M Leech, M. Ganis, Y. Lee, etc.,    RFC 1928, March 1996

1. A system arranged to provide a gateway between a first network and asecond network, the system comprising: interface means to receive fromthe first network a message intended for an object in the secondnetwork, the message including an identifier for a further object ineither the first or second network; means to generate further interfacemeans for receiving from the second network messages for the furtherobject; means to form a new identifier for the further interface means,the new identifier including check data resulting from a hash operationfor checking the validity of the or at least part of the new identifier;means to replace the received identifier with the new identifier in themessage; and means to forward the message to the object in the secondnetwork.
 2. A system according to claim 1, wherein the new identifierincludes information to enable subsequent recovery by the system of thereceived identifier.
 3. A system according to claim 2, wherein the newidentifier includes a representation of the received identifier.
 4. Asystem according to claim 2, wherein the new identifier includes anindication of the identity of the received identifier and the systemincludes means to associate said indication with said receivedidentifier.
 5. A system according to claim 1, comprising means toinclude in the new identifier a name tag to identify the interfacemeans.
 6. A system according to claim 1, wherein the check data furthercomprises a secret.
 7. A system according to claim 1, comprising meansto include in the new identifier an indication that the receivedidentifier was received in an message from the first (or second)network.
 8. A system according to claim 1, comprising means to determinewhether the received identifier originated from the first network or thesecond network.
 9. A system according to claim 8, comprising means toform the new identifier on the basis of the determined origin.
 10. Asystem according to claim 9, wherein, if the received identifieroriginated in the first network, the means to form the new identifierforms a new identifier including information to enable subsequentrecovery by the system of the received identifier.
 11. A systemaccording to claim 9, wherein, if the received identifier originated inthe second network, having passed through the system from the secondnetwork to the first network, the means to form the new identifier formsa new identifier comprising an original identifier recovered frominformation included in the received identifier.
 12. A system accordingto claim 9, wherein, if the received identifier originated in the firstnetwork, having passed through the system from the first network to thesecond network and having passed back to the first network other thanthrough the system, the means to form the new identifier forms the newidentifier as a copy of the received identifier.
 13. A system accordingto claim 1, comprising means to detect a name tag in the message.
 14. Asystem according to claim 13, comprising means to determine on the basisof the name tag whether the object in the second network is valid and isstill available to receive messages.
 15. A system according to claim 14,wherein the means to determine initiates a call to a naming service, thenaming service being configurable by an authorised party by adding orremoving name tags, and the presence or absence of a name tag beingindicative of whether the object associated with the name tag isavailable or not respectively.
 16. A system according to claim 1,comprising means to verify the received identifier.
 17. A systemaccording to claim 16, wherein identifier includes check data to enableverification of the received identifier.
 18. A system according to claim17, wherein the check data is the result of a hash operation enacted onat least part of the identifier and a secret, and the means to verifythe received identifier is configured to enact a similar hash operationon the same part of the identifier and a secret and compare theresulting check data with the received check data.
 19. A systemaccording to claim 18, wherein the secret is stored by and onlyaccessible by the gateway.
 20. A system according to claim 1, whereinthe means to generate the further interface means comprises means todetermine on the basis of the received identifier whether a template foran appropriate further interface means is already known to the system.21. A system according to claim 20, wherein the means to generate thefurther interface means comprises means, which is operable in the eventan appropriate template is not known to the system, to obtain anappropriate template from a remote repository.
 22. A system according toclaim 20, wherein the means to generate the further interface meanscomprises means, which is operable in the event no appropriate templateis known to the system and/or an appropriate template is not recoverablefrom a remote repository, to obtain a generic template.
 23. A systemaccording to claim 20, wherein the means to generate the furtherinterface is arranged to at least obtain a template for the furtherinterface means on or after receipt of the received identifier and inadvance of receipt of a message for the further object.
 24. A systemaccording to claim 1 configured for operation in a trusted operatingsystem.
 25. A system according to claim 24, wherein the trustedoperating system enforces Mandatory Access Control.
 26. A systemaccording to claim 25, comprising at least two logical compartments anda trusted relay process that has privileges necessary to pass messagesbetween the two compartments, wherein the first network and therespective interface means are associated with a first compartment andthe second network is associated with a second compartment.
 27. A systemaccording to claim 25, wherein a secret, usable by the system in a hashoperation for validating object references, is associated with a thirdcompartment, and wherein only the trusted relay process has theprivileges necessary to retrieve the secret from the further compartmentin order to enact a hash operation.
 28. A system according to claim 1,wherein the received identifier is an Interoperable Object Referencehaving the form IOR[host: port: key].
 29. A system according to claim 1,wherein the new identifier is an Interoperable Object Reference havingthe form IOR[host x: port x: key x], wherein key x includes informationto enable subsequent recovery by the system of the received identifier.30. A system according to claim 29, wherein key x includes arepresentation of the received object reference IOR[host i: port i: keyi].
 31. A system according to claim 29, wherein key x includes: anidentifier to indicate from which network the object referenceoriginated; a name tag associated with an identity of the gatewayprocess; and check data for verifying the validity of the objectreference.
 32. The system according to claim 1, wherein the furtherinterface means corresponds to the further object and the furtherinterface means is generated only when or after the message includingthe identifier for the further object is received.
 33. A method ofcontrolling a gateway to pass messages for objects between first andsecond networks attached to the gateway, the method comprising the stepsof: receiving from the first network a message for an object in thesecond network, the message including an identifier for a further objectin either the first or second network; generating means to receivemessages for the further object; forming a new identifier for the meansto receive messages for the further object, the new identifier includingcheck data resulting from a hash operation for checking the validity ofthe or at least part of the new identifier; replacing the receivedidentifier with the new identifier in the message; and forwarding themessage to the object in the second network.
 34. The method of claim 33,wherein the further interface means corresponds to the further objectand the further interface means is generated only when or after themessage including the identifier for the further object is received.